Field of the Invention
The present invention relates to classloading in a virtual machine and more particularly to runtime classloader determination for class objects executing in a virtual machine.
Description of the Related Art
The class loader mechanism forms part of the foundation of the modern, virtual machine. In particular, classloaders provide the translation technology that can convert serialized byte code into named classes for execution in the virtual machine. Notably, classloaders can perform this conversion regardless of the storage means and location of the byte code. As a result, the virtual machine need not know the operational specifics associated with the file systems storing the byte code. In conventional runtime environments like the Java® runtime environment (Java is a trademark of Sun Microsystems of Palo Alto, Calif., United States), classes can be introduced when they are referenced by name in a class that already is executing within the runtime environment. While the entry point class of an application can require some individual processing exclusive of the classloading mechanism, subsequent attempts at loading other classes are performed exclusively by the class loader.
In the Java runtime environment, the virtual machine can include one class loader embedded within the virtual machine. Referred to as the “primordial” class loader, this embedded class loader automatically resolves references to class names by reference to a specified repository of trusted classes which can be run by the virtual machine without verification. Earlier class loading technology permitted developers to load classes from a variety of disparate locations, including file systems, remote hosts, and the like. Yet, this type of flexibility carried the price of complexity. More recent class loading technology reduces this complexity using a parent/child delegation model in which each customized class loader delegates class loading to its parent class loader that either can be another customized class loader or the primordial class loader.
Application servers permit application isolation through extensive use of customized class loading. In particular, in the virtual machine environment, each class can be defined by a class name and the classloader that loaded the class. Hence, a class can be loaded only once by a given class. Still, the same class can be loaded multiple times using separate classloaders within the same virtual machine. As a result, applications can be isolated in the virtual machine. Moreover, different versions of the same class can be utilized in different applications simultaneously. Of note, distributed technologies such as Open Services Gateway Initiative (OSGi) framework depend upon the isolation of applications afforded by customized class loading.
Recent advancements in component based application development including that prevalent in the OSGi framework permit the use of scripting languages not native to the virtual machine in source code that is native to the virtual machine. Examples include Java Server Page (JSP) technology, “facelets” and the like. Upon deployment, the non-native scripts can be translated into native source code by a corresponding container, such as a JSP container. Thereafter, the translated source code can be compiled and executed in the application server environment. During the translation phase, however, the classloader implicated for the translated source code will be associated with the container and not necessarily the application server environment in which the translated source code once compiled is deployed. Thus, an inconsistency in classloader specification can arise.